I've flipped this back to a draft PR as currently the functions in the __builtins_msvc module can be used only when the -i switch is supplied on the command-line.
I think it might be that semantic3 isn't getting run on that module's functions when -i isn't supplied—but I'm unsure.

This is still a draft as I'm unable to get the compiler to actually generate code for the __builtins_msvc module without its path being supplied on the command-line.

Presently, neither the __builtins module nor the __builtins_msvc module make their way into the array of modules passed into generateCodeAndWrite, which is fine for __builtins, but not for __builtins_msvc because of how the standard Windows headers use the builtins, and because DMD doesn't inline some of the asm-using functions.

This is effectively how winnt.h declares UnsignedMultiply128:

unsigned long long UnsignedMultiply128 (unsigned long long Multiplier, unsigned long long Multiplicand, unsigned long long *HighProduct);

#define UnsignedMultiply128 _umul128

unsigned long long UnsignedMultiply128 (unsigned long long Multiplier, unsigned long long Multiplicand, unsigned long long *HighProduct);

which will expand to unsigned long long _umul128 (unsigned long long Multiplier, unsigned long long Multiplicand, unsigned long long *HighProduct);, causing the linker to expect code for _umul128.

But even if the Windows headers didn't do that, we still need code to be generated for _umul128, because DMD won't inline _umul128's call to multiplyWithDoubleWidthProduct and the linker will expect code for it.

(_umul128 isn't the only function affected.)

Right now I'm stuck, because I've yet to figure out a good way to get the __builtins_msvc module into the modules array passed into generateCodeAndWrite after it's conditionally imported if any MSVC intrinsics are detected.

The best I've come up with thus far is very hacky, and would require the same changes to be made in LDC and GDC (unless I'm mistaken), which is: in Module.parseModule, if the module identifier is __builtins_msvc, set the global includeImports to true, and if it was previously false set includeByDefault to false, then add __builtins_msvc to the compiledImports array.

In short, my question is: is there an existing way to make it so the __builtins_msvc module winds up getting passed to generateCodeAndWrite after it gets imported by CParser.parseModule?
And, if not, is there an acceptably non-hacky way to thread it through the compiler without requiring changes to LDC and GDC?

Any suggestions would be appreciated.

I suggest having the user do the #include line as the first line in his C code. Or have the user pass it in with the dmd switch that passes switches to the C preprocessor. Will that work?

@WalterBright,

I suggest having the user do the #include line as the first line in his C code. Or have the user pass it in with the dmd switch that passes switches to the C preprocessor. Will that work?

If that works for you, it works for me.
I don't see an issue with:

#include <importc_msvc_builtins.h>
#include <windows.h>

I've added some code to supply <path>/importc.h/../include to the preprocessor as an include path, so that the user doesn't have to hunt down the path themselves. (de63140)

Though, the issue of these builtins only working when the -i switch is used still remains.

Is there an existing way to force codegen for an imported module, when the -i switch isn't used?

Okay; a separate PR adding a mechanism that this PR can use to force codegen for the __builtins_msvc module: #16443

Via something like this in cparse.d:

         if (token.value == TOK._import) // import declaration extension
         {
             auto a = parseImport();
             if (a && a.length)
/*+*/        {
/*+*/            auto imp = (*a)[0].isImport();
/*+*/            imp.forceCodegen = imp.id == Id.builtins_msvc;
                 symbols.append(a);
/*+*/        }
             return;
         }

Though, the issue of these builtins only working when the -i switch is used still remains.

Is there an existing way to force codegen for an imported module, when the -i switch isn't used?

Did you try converting these functions to templates?

Though, the issue of these builtins only working when the -i switch is used still remains.
Is there an existing way to force codegen for an imported module, when the -i switch isn't used?

Did you try converting these functions to templates?

I did—but no dice, unfortunately, even with all the affected functions being templates, the simplest possible usage still fails to link:

// windows_h_c.c:
#include <importc_msvc_builtins.h>
#include <windows.h>

// windows_h.d:
pragma(lib, "MinCore");
import windows_h_c;

windows_h.obj : error LNK2019: unresolved external symbol _InterlockedExchangeAdd referenced in function _InlineInterlockedAdd
windows_h.obj : error LNK2019: unresolved external symbol _InterlockedExchangeAdd64 referenced in function _InlineInterlockedAdd64
windows_h.obj : error LNK2019: unresolved external symbol _mul128 referenced in function MultiplyExtract128
windows_h.obj : error LNK2019: unresolved external symbol __shiftright128 referenced in function MultiplyExtract128
windows_h.obj : error LNK2019: unresolved external symbol _umul128 referenced in function UnsignedMultiplyExtract128
windows_h.obj : error LNK2019: unresolved external symbol _ReadWriteBarrier referenced in function BarrierAfterRead
windows_h.obj : error LNK2019: unresolved external symbol __stosb referenced in function RtlSecureZeroMemory
windows_h.obj : error LNK2019: unresolved external symbol __readgsqword referenced in function NtCurrentTeb
windows_h.exe : fatal error LNK1120: 8 unresolved externals

Just have the user add the #include line.

Just have the user add the #include line.

Perhaps I'm misunderstanding you, but is that not what the current implementation is doing?
In the example here: #16372 (comment)

There, the user #includes <importc_msvc_builtins.h> before <windows.h>, which works perfectly well.
importc_msvc_builtins.h then does an __import __builtins_msvc;
The import of __builtins_msvc succeeds because druntime/import is in the compiler's import path.
But because the path to __builtins_msvc.d wasn't explicitly provided on the command-line, codegen doesn't take place for the __builtins_msvc module.
Which ultimately causes the linker to fail because the way the standard Windows headers uses some of these intrinsics causes the linker to expect a definition for them.

/tmpfs/dautotest-work/repo/dlang.org/web/spec/importc.html:145: [RAW MACRO LEAKAGE] $(SPEC_S ImportC,
/tmpfs/dautotest-work/repo/dlang.org/web/dlangspec.html:40232: [RAW MACRO LEAKAGE] $(SPEC_S ImportC,
2 errors found. Exiting.

is coming somewhere from the spec changes but I can't see where.

A paragraph was missing its closing bracket: fixed now

LDC now defines __IMPORTC_LDC__, and I'm going to take it that there are no qualms to defining __IMPORTC_DMD__, so __assume is grand now.

I've double-checked that all the intrinsics work as they should when compiled with DMD, LDC, and GDC.

I now consider this PR fully ready for final review (and hopefully merging).

As a reminder, I've split the implementation of the intrinsics up into a few-dozen commits to aid in reviewing them.

(P.S. please don't squash-merge this, no one wants a single commit that big!)

(P.S. please don't squash-merge this, no one wants a single commit that big!)

I'd rather not have 89 commits though.

(P.S. please don't squash-merge this, no one wants a single commit that big!)

I'd rather not have 89 commits though.

That's understandable. I (or someone else) can rebase the commits into two-or-three commits after review?

I think the massive __builtins_msvc.d commit should be separate from the compiler changes, at least.

Sounds good.